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1. REAL PARTY IN INTEREST 

The real party in interest is General Electric Company, the Assignee of the above- 
referenced application by virtue of the Assignment to General Electric Medical 
Technology Services, Inc. recorded on February 12, 2001, at reel 01 1585, frame 0816. 

2. RELATED APPEALS AND INTERFERENCES 

Appellant is unaware of any other appeals or interferences related to this Appeal. 
The undersigned is Appellant's legal representative in this Appeal. General Electric 
Company, the Assignee of the above-referenced application, as evidenced by the 
documents mentioned above, will be directly affected by the Board's decision in the 
pending appeal. 

3. STATUS OF THE CLAIMS 

Claims 1-26 are currently pending, and claims 1-26 are currently under final 
rejection and, thus, are the subject of this appeal. 

4. STATUS OF AMENDMENTS 

The Appellant has not submitted any amendments subsequent to the Final Office 
Action mailed on November 13, 2003. 

5. SUMMARY OF THE INVENTION AND OF THE DISCLOSED 
EMBODIMENTS 

The present invention relates to allowing remote enablement of software-based 
options for a predetermined time period in remotely installed equipment, such as medical 
diagnostic equipment 10. See Application pg. 1, H 1. Specifically, the invention relates 
to a system and method to automatically and remotely enable software-based options for 
a trial period in remotely installed equipment 10. Id. at pg. 4, If 1. 

In accordance with one embodiment, a method to remotely enable software- 
enabled options includes receiving a user I.D. 102 at a centralized facility 16 from a user, 
and receiving an option-enabling request from the user specifying an option requested to 
be enabled in the equipment 26, 30, 32, 34 at the subscribing station 1 10. Id. at pg. 4, ^[ 
4. Furthermore, the invention includes confirming that the option has not already been 
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enabled 118 at the centralized facility 16 and sending an enabling feature from the 
centralized facility 16 to the equipment 26, 30, 32, 34 in the subscribing station 12, 14 to 
activate the option 132 in the equipment 26, 30, 32, 34. Id. at Pg. 5, If 1. 

In accordance with another embodiment of the current invention, a computer 
program is claimed which, when executed by a computer 42, will cause the computer 42 
to receive an option-enabling request from a user to request an option be enabled 1 10 in a 
medical device 26, 30, 32, 34 located remotely from an on-line center 16. Id. at Pg. 5, H 
2. A system I.D. is received 1 12 by the computer 42 and validated 112 with data from a 
database 68 at the on-line center 16. Id. The option-enabling request will then be 
compared with any other option request for that particular system 118 and rejected if the 
option-enabling request has previously been enabled 120. Id. Otherwise, the computer 
42 will generate an option key 124 and forward the option key to either the user to 
manually enable the option 140, or directly to the medical device to automatically enable 
the option 130. Id. 

In accordance with another embodiment, a computer data signal embodied in a 
carrier wave and representing a set of instructions which, when executed by a processor 
of a computer 42, will cause the processor to enable an option in a device 26, 30, 32, 34 
by receiving a user I.D. 102 at a centralized facility 16 from a user. An option-enabling 
request is also received from the user specifying which option the user requests to be 
enabled 1 10 in the particular device 26, 30, 32, 34 at a remote subscribing station 12, 14. 
The set of instructions also includes confirming that the option has not already been 
enabled 118, and sending an enabling feature 130, 140, such as a software key 124, from 
the centralized facility 16 to the device 26, 30, 32, 34 in the remote subscribing station 
12, 14 for activating the option in the device 26, 30, 32, 34. 

6. ISSUES 

Whether claims 1-3, 6, 7, 10-12, 14, 23, 24, and 26 are anticipated by 
Neville et al. (USP 6,272,636) under 35 U.S.C. §102(e). Also, whether claims 4, 5, 13, 
15, and 25 are unpatentable under 35 U.S.C. § 103(a) over the single reference Neville et 
al. Furthermore, whether claims 8, 9, and 16 are unpatentable under 35 U.S.C. §103(a) 
over Neville et al. in view of Linden et al. (USP 6,360,254). Finally, whether claims 17- 
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22 are unpatentable under 35 U.S.C. § 103(a) over Neville et al. in view of Earnest (USP 
4,888,798). 

7. GROUPING OF CLAIMS 

The Examiner has provided a combination of grounds for rejection which 
Appellant contests. As will be particularly explained in the Argument Section, claims 1, 
8-10, 13, 10, 16, 18, and 23 contain subject matter that is patentably distinct from the art 
of record. Therefore, as will be shown below, claims 1, 8-10, 13, 10, 16, 18, and 23 do 
not all stand or fall together because at least each of these claims include subject matter 
that is patentably distinct from the art of record. 

8. ARGUMENT 

As discussed in detail below, the Examiner has improperly rejected the pending 
claims. The Examiner has misapplied long-standing and binding legal precedents and 
principles in rejecting the claims under Sections 102(e) and 103(a). Accordingly, Appellant 
respectfully requests full and favorable consideration by the Board, and ultimate allowance 
of claims 1-26 as Appellant believes claims 1-26 are currently in condition for allowance. 
Background 

While the claimed invention is directed to remotely enabling specific options of a 
device that were previously disabled, the applied art, and specifically Neville et al., is 
directed to a system to control an end user's execution of a digital product during an 
evaluation period. Neville et al. teaches a system whereby an end user can execute an 
evaluation copy of a specific digital product and, if so desired, follow a sequence of steps 
to purchase the non-evaluation version of the digital product. 

Neville et al. teaches a system that employs "metering," whereby upon an attempt 
to execute an evaluation version of a digital product, the evaluation version 
communicates with a server/clearinghouse to determine whether the evaluation version 
can be used by that particular end user at the particular time of the request. See Col. 13, 
Ins. 20-3 1 . If the server/clearinghouse determines that the user is within the evaluation 
period, the server/clearinghouse then transmits an unlock key to the evaluation version of 
the digital product, thereby allowing the digital product to execute for that particular 
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instance. Id. However, if the server/clearing house determines that the end user is outside 
of the evaluation period, the user is informed that the digital product cannot be executed. 
Id. at Ins. 31-35. This "approval process," including downloading the unlock key, must 
be repeated each and every time the user wishes to execute the evaluation version of the 
digital product. Simply, Neville et al. teaches a system of "execution control." This 
means that just prior to every execution of a digital product, approval from a 
server/clearinghouse must be secured before the application is allowed to start. See Title 
of Neville et al. and Col. 13, Ins. 20-35. 

On the other hand, the claimed invention is directed to enabling previously 
disabled options on a device. In Neville et al., the digital product may have use 
restrictions, or limitations, but it is still enabled from the very beginning of installation. 
The digital product of Neville et al. is only "disabled" after a trial period ends. At that 
point, there is no disclosure in Neville et al. to perform remote enabling, as is currently 
claimed. Specifically, Neville et al. states that "[a] purchase step may be incorporated 
into the execution control procedures described herein" but fails to teach or suggest how 
such would be accomplished and certainly does not teach or suggest the claimed 
technique. Col. 17, Ins. 1-3. 

The Examiner tries to equate the per-use "execution control" of Neville et al, to 
the remote enablement, but the two are distinct. One allows restricted use for a trial 
(Neville et al.), while the other prevents any use until enabled. The claimed invention 
does not control and monitor each individual execution of a specific digital product, as in 
Neville et al., but rather enables a specific option in an overall system via a distinct 
technique for remotely enabling options. Appellant contends that numerous distinctions 
will become apparent upon a detailed analysis of the claimed invention and the art of 
record as set forth below. 

Rejections Under §102(e) 

Independent Claim 1 

Regarding claim 1, this claim, in part, calls for "receiving a user I.D. at a 
centralized facility from a user," "receiving an option-enabling request from the user 
specifying an option requested to be enabled in equipment at a subscribing station," and 
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"at the centralized facility, confirming that the option has not already been enabled." 
Contrary to the Examiner's assertions, Neville et al. does not teach such. 

Neville et al. does not teach "receiving a user I.D. at a centralized facility from a 
user ." Rather, in the very section cited by the Examiner as teaching that which is 
claimed, Neville et al. actually teaches that "[t]he client application executing on the end- 
user computing device provides a request/user ID to the server clearinghouse." Col. 13, 
Ins. 18-20. This distinction is indicative of a fundamental difference between the 
objectives of the claimed invention and Neville et al. That is, Neville et al. is concerned 
with a "form of control to prevent unauthorized use of the digital product while still 
making the product widely available for consumer evaluation." Col. 1, Ins. 61-64. 
Neville et al. identifies that previous attempts to implement execution control include 
providing the user with a "crippled" version of the non-evaluation version digital product. 
See Col. 2, Ins. 12-33. Neville et al. states that such "crippled" versions are unacceptable 
to meet the demands of the user to evaluate the product. See Col. 2, Ins. 28-33. 
Therefore, in order to allow optimal consumer evaluation, the execution control of 
Neville et al. is implemented by the computing device so that the user is presented with 
an evaluation experience that accurately represents the regular version of the digital 
product. See Col. 4, Ins. 34-49. Accordingly, Neville et al. teaches that "[t]he client 
a pplication ... provides a request/user ID to the server clearinghouse." Col. 13, 18-20 
(emphasis added). Therefore, Neville et al. does not teach that a request is received from 
a user , as claimed. 

Additionally, Neville et al. does not teach the element of "receiving an option- 
enabling request from the user specifying an option requested to be enabled in equipment 
at a subscribing station." Simply, Neville et al. is directed to execution control of an 
entire executable digital product. See Col. 4, Ins. 52-60. Neville et al. teaches that "[t]he 
client application executing on the end-user computing device provides a request/user ID 
to the server/clearinghouse," whereby the server/clearinghouse "tracks requests by this 
user to execute this digital product" and "determines whether the user is authorized to 
execute the application." Col. 13, Ins. 19-25. Therefore, Neville et al. teaches only a 
request for execution of the digital product. Simply, Neville et al. does not teach 
"specifying an option requested" because the only request communicated is to request 
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execution of the entirety of the specific product. There is no such "option" taught or 
suggested in Neville et al. This distinction illustrates one fundamental difference 
between the claimed invention and Neville et al. Specifically, this element of the claimed 
invention is directed to activating options in equipment , while Neville et al. is directed to 
controlling activation of entire digital products . 

Further, Neville et al. does not teach the element of "confirming that the option 
has not already been enabled." Specifically, such would not be consistent with the 
execution control system of Neville et al. because if the execution controlled digital 
product were already activated, it would not request activation. That is, since the very 
digital product that requires an activation request also makes the request, it is unnecessary 
for Neville et al. to confirm "that the option has not already been enabled," as claimed. 
Therefore, Neville et al. does not teach that which is affirmatively claimed, and actually 
leads one away from conducting such a step. Therefore, Neville et al. does not teach the 
claimed step and cannot be interpreted as even suggesting such a step. 

For all of these reasons, claim 1 is patentably distinct from the art cited. Claims 
2-9 are believed to be in condition for allowance at least pursuant to the chain of 
dependency. Furthermore, claims 8 and 9 are believed to include distinguishing subject 
matter; however, since claims 8 and 9 were rejected under § 103(a), Appellant will 
address claims 8 and 9 in the corresponding section below. 

Independent Claim 10 

Regarding claim 10, the Examiner stated that "Neville et al. also teach validating 
an options request, creating an option key in response thereto , a communications network 
for relaying data, and transmitting the option key through an external communications 
network('636, column 10, lines 62-65; column/line 13/13-14/15)." See Office Action 
mailed November 13, 2003, Pg. 4, U 2. However, the cited section does not support the 
Examiner's contention. In fact, just before the section cited by the Examiner, Neville et 
al. teaches that "[t]he server stores a symmetric unlock key used previously by the builder 
(FIG. 7) to encrypt selected portions of the metered application, e.g., code section 302 
(FIG. 4) and entries 408 in section table 300d\" Col. 10, Ins 46-50. Therefore, contrary 
to the Examiner's assertion, the server of Neville et al. does not create an option key in 
response to an option request. Rather, Neville et al. is clear that any "unlock key" is 
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created well before any request because Neville et al.'s unlock key is necessary to build 
the very execution controlled product that ultimately makes a request. Id. Accordingly, 
Neville et al teaches that the server does not generate an unlock key but instead retrieves 
and sends a "stored " unlock key. Id. 

One of ordinary skill in the art will readily recognize that there is a distinct 
difference between retrieving a previously stored key in response to a request and 
generating anew, a key in response to a request. Simply, Neville et al. teaches that all 
keys are created when building an execution controlled product. Therefore, Neville et al. 
teaches that the keys are stored by the server and later retrieved and supplied upon 
request and are not created . Id. Therefore, Neville et al. does not teach "an on-line center 
capable of receiving and authenticating a user I.D....and creating an option key in 
response thereto," as claimed. 

Accordingly, claim 10 is patentably distinct from the cited art. Therefore, for at 
least the above reasons, claim 10 must be fully considered for patentability independent 
of any group. Furthermore, claims 11-17 are in condition for allowance at least pursuant 
to the chain of dependency. 

Claims Dependent Upon Independent Claim 10 

Although, as stated above, claims 11-17 are at least patentably distinct from the 
art of record due to the chain of dependency, Appellant believes claim 14 contains 
subject matter that is additionally distinguishable from the art of record. Therefore, claim 
14 does not stand or fall with any group and must be independently reviewed. 

Specifically, claim 14 calls for the computer to be "further programmed to send 
an electronic verification of the option enablement." However, not only does Neville et 
al. fail to teach or suggest any such electronic verification, the Examiner failed to address 
the explicitly called for element. 

To anticipate a claim, the reference must teach each and every element of the 
claim. See MPEP §2131. As stated, however, Neville et al. does not teach that which is 
called for in claim 14 and the Examiner did not provide any analysis or reasoning for the 
§ 102(e) rejection. Therefore, for at least this reason, claim 14 is patentably distinct from 
the art of record and must be fully consider for patentability apart from any group. 
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Independent Claim 23 

Regarding claim 23, the Examiner failed to specifically address the elements of 
claim 23. Rather, the Examiner rejected claim 23 under the same assertions applied to 
claim 1. As such, Appellant incorporates herein the relevant remarks with respect to 
claim 1. However, contrary to the Examiner's rejection, claim 23 includes unique 
elements that must be independently addressed. Furthermore, due to the following 
distinctions, claim 23 must be fully considered for patentability apart from any group. 

At the very least, Neville et al. does not teach "receiving an option-enabling 
request specifying an option requested to be enabled in the device at a subscribing 
station." That is, Neville et al. does not teach specifying any option requested because 
the only request communicated is to request execution of the specific product contacting 
the server/clearinghouse, not an option thereof. See Col. 13, Ins. 19-25. 

Furthermore, Neville et al. does not teach "confirming that the option has not 
already been enabled," as claimed. That is, Neville et al. teaches that the very digital 
product that requires an activation request makes the request. See Col. 13, Ins. 18-31. 
Therefore, Neville et al. does not teach such confirmation and, in fact, it is unnecessary 
for the system of Neville et al. to confirm "that the option has not already been enabled" 
because an active product would not be caused to make another request during a period 
of previous activation. 

For at least these reasons, claim 23 is patentably distinct from the art of record. 
Additionally, Appellant believes claims 24-26 are in condition for allowance at least 
pursuant to the chain of dependency. 
Rejections Under §103(a) 

The Examiner has fallen drastically short of the standard that must be met in order 
to sustain a rejection under § 103(a). The burden of establishing a prima facie case of 
obviousness falls on the Examiner. MPEP §2142. Obviousness cannot be established by 
combining the teachings of the prior art to produce the claimed invention absent some 
teaching or suggestion supporting the combination. ACS Hospital Systems, Inc. v. 
Montefiore Hospital 732 F.2d 1572, 1577, 221 U.S.P.Q. 929, 933 (Fed. Cir. 1984). 
Accordingly, to establish a prima facie case, the Examiner must not only show that the 
combination includes each and every element of the claimed invention, but also provide 
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"a convincing line of reasoning as to why the artisan would have found the claimed 
invention to have been obvious in light of the teachings of the references. 11 Ex parte 
Clapp, 227 USPQ 972, 973 (Bd. Pat. App. & Inter. 1985). 

In particular, to establish a prima facie case of obviousness, the Examiner must 
affirmatively establish three independent and distinct criteria as follows: 

To establish a prima facie case of obviousness, three basic criteria must be 
met. First there must be some suggestion or motivation, either in the 
references themselves or in the knowledge generally available to one of 
ordinary skill in the art, to modify the reference or to combine reference 
teachings. Second , there must be a reasonable expectation of success. 
Finally , the prior art reference (or references when combined) must teach 
or suggest all the claim limitations. 
MPEP §2143 

As will be shown, the Examiner has clearly failed to establish a prima facie case 
of obviousness. 

Claims Dependent Upon Independent Claim 1 
Although, as stated above, claims 2-9 are patentable at least due to the chain of 
dependency, Appellant believes claims 8 and 9 contain subject matter that is additionally 
distinguishable from the art of record. Therefore, claims 8 and 9 do not stand or fall with 
any group and must be independently reviewed. 

Regarding claim 8, which calls for "sending the enabling feature by one of FTP 
and email to a field engineer for manual installation and enablement of the feature," the 
Examiner asserted that Linden et al. teaches "a secure method for enabling a remote 
computer to access resource comprising sending an enabling feature by e-mail and 
sending a verification e-mail to the user confirming option enablement (column 1 1 , lines 
28-39)." Office Action mailed November 13, 2003, pg. 5, ]f 4. However, Linden et al. is 
directed to a system and method for providing URL-type access to private resource and 
the cited section actually states: 

Another application (not separately illustrated) involves providing 
restricted access to account information in the context of orders for goods. 
In one embodiment, for example, when a user 70 (FIG. 2) places an order 
on a merchant's Web site 30, the private URL/hyperlink 74 is transmitted 
to the user via an order confirmation email 72, and provides access to a 
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private Web page 78 that includes order status information or other 
account-related information. The private Web page 78 may include links 
or a form for allowing the user to modify the order. 
Linden et al., Col. 11, Ins. 28-39. 

Therefore, one of ordinary skill in the art will readily recognize that the 
Examiner's rejection impermissibly attempted to combine or modify references (1) 
without suggestion or motivation and (2) without a reasonable expectation of success and 
(3) even if combinable, the combination fails to teach each and every element claimed. 

In particular, one would not be motivated to combine a system for controlling 
execution of a digital product for purposes of evaluating the digital product as taught by 
Neville et al, with a system for enabling secure URL-type access to private information, 
as taught by Linden et al. Simply, the systems are unrelated and uncombinable. The use 
of these unrelated references is clearly the result of a key-word search that is wholly 
based on the present disclosure irrespective of the actual teachings of the references. The 
Examiner is using the present application as a roadmap to piece together references that 
are not technically combinable in this manner. Such is impermissible use of hindsight 
reconstruction. Furthermore, such a combination of unrelated systems and methods 
would not reasonably be expected to succeed, at least not for the purpose of the claimed 
invention. 

Regarding claim 9, the Examiner again failed to meet the burden required to 
establish a prima facie case of obviousness. Specifically, claim 9 calls for 'Verifying the 
option activation" and "sending a verification email to the user confirming option 
enablement." The Examiner's basis for the rejection of claim 9 was the reasoning 
addressed with respect to claim 8. Therefore, as previously shown with respect to claim 
8, the Examiner's rejection impermissibly combines or modifies references (1) without 
suggestion or motivation, (2) without a reasonable expectation of success, and (3) even 
when combine, the combination fails to teach each and every element claimed. 

As such, claim 9 is also patentably distinct from the art of record. Furthermore, 
due to these distinctions, claim 9 must be considered for patentability independent from 
any group. 
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Claims Dependent Upon Independent Claim 10 

The Examiner ignored elements of claim 1 1 in proffering a rejection of the claim. 
Claim 1 1 calls for the receipt of "a user I.D." and "if the user LD. is validated, receiving] 
a system LD. and validating] the system LD." claim 1 1 is therefore clear that a system 
I.D. cannot be the equivalent of a user LD. As will be addressed in detail with respect to 
the "Newly Presented Rejection in Interview Summaries" section below, nowhere does 
the art of record teach or suggest the use of both a user LD. and a system I.D. 
Furthermore, the art of record certainly does not teach or suggest the use of a user LD. 
and a system I.D. in the manner claimed. Therefore, claim 1 1 is patentably distinct from 
the art of record and must be considered for patentability independent from any group. 

The Examiner also failed to adequately address claim 13.. Claim 13 calls for the 
computer to "download and install the option key in medical equipment at the 
subscribing station" and "verify option enablement in the medical equipment." However, 
the combination of Neville et al. and Linden et al. fails to teach or suggest such. 

Beyond the fact that (1) there is no suggestion or motivation to combine the 
references and (2) any combination would not have a reasonable expectation of success, 
(3) Neville et al. simply does not teach or suggest verification of option enablement. The 
Examiner's rejection of claim 13 entirely fails to address these limitations. The Examiner 
seems to have ignored explicit claim limitations. 

As such, claim 13 is also patentably distinct from the art of record. Due to these 
distinctions, claim 13 must be considered for patentability independent from any group. 

The Examiner rejected claim 16 under the same basis applied to claims 8 and 9. 
As previously shown, the rejection of claims 8 and 9 was improper under MPEP §2143. 
The rejection falls well short of establishing a prima facie case of obviousness. For at 
least these reasons, claim 16 is also patentably distinct from the art of record. Due to 
these distinctions, claim 16 must be considered for patentability independent from any 
group. 

Independent Claim 18 
The Examiner asserted that claim 18 is unpatentable over Neville et al. in view of 
Ernest. However, neither reference teaches or suggests a comparison of "the option- 
enabling request with any other option requests for that system I.D." As previously 
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shown, Neville et al. only determines whether the digital product requesting an "unlock 
key" is outside the evaluation period and, if so, declines to fulfill the request. See Col. 2, 
Ins. 28-34 and col. 13, Ins. 31-35. 

Additionally, Earnest does not "compare the option-enabling request with any 
other option requests for that system I.D." Rather, the only comparing taught by Earnest 
is to compare a new transformed key to a stored key. See Col. 3, Ins. 49-52 and col. 4, 
Ins. 44-63. One of ordinary skill in the art will readily recognize that the stored key of 
Earnest is typical in key authentication systems and is not the same as a system I.D. 
because, as defined in the Specification, a system I.D. identifies a particular piece of 
equipment making an enabling request. Pg. 13, \ 2. It is clear that the keys taught by 
Earnest do not function as claimed and are not equivalent. The keys taught by Earnest 
are in no way a system I.D., as claimed. 

As such, claim 18 is patentably distinct from the art. Therefore, for at least these 
reasons, claim 18 must be considered for patentability separately from any group. 
Accordingly, claims 19-22 are in condition for allowance pursuant to the chain of 
dependency. 

Newly Presented Rejection in Interview Summaries 

In a telephone interview on January 9, 2004, Appellant's counsel asked the 
Examiner for his interpretation of specific elements of each independent claim and 
pointed out that Appellant's counsel believed that the prior art lacked teaching or 
suggesting of those elements. Discussion followed and no agreement was reached. 

However, on one point in particular, Appellant's counsel questioned the 
Examiner's assertion in the Final Office Action mailed November 13, 2003, that 'the 
Appellant has not eliminated the possibility of a system ID being equivalent to a user 
ID." Aside from differences defined in the specification, Appellant's counsel pointed out 
that claim 1 1 calls for the receipt of "a user I.D." and "if the user I.D. is validated, 
receiving] a system I.D. and validating] the system I.D." and, therefore, claim 11 is 
clear that a system I.D. cannot be the equivalent of a user I.D. The Specification defines 
user I.D. and system I.D. as an identifier for a field engineer or authorized customer 
making a request and an identifier for a particular piece of equipment making an enabling 
request, respectively. Pg. 13, If 2. 
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The Examiner explained that no consideration of these elements of claim 1 1 were 
afforded because, in the Examiner's opinion, the elements contain "improper conditional 
language." Although the Examiner never articulated such a rejection in the file history, , 
the Examiner explained that claim elements containing "conditional language" 
employing an "if-then" statement are open-ended, improper, and need not be considered 
by the Examiner when examining the application. The Examiner asserted that "if-then" 
statements are not proper without an "else" and; therefore, the Examiner gave these claim 
elements no patentable weight in examination. 

Appellant's counsel explained that the Examiner's decision to ignore entire 
elements of claims containing an "if-then" statement is improper under the MPEP, 
C.F.R., and substantive case law. However, the Examiner insisted that an "if-then" 
statement may be properly disregarded if it does not include an "else" and, as such, the 
Examiner squarely admitted that when examining claims 11, 18, and 23 of the present 
application, the Examiner entirely ignored any element that included an "if-then" 
statement. Appellant's counsel requested that the Examiner provide an Interview 
Summary explaining the Examiner's position and requested citations to the MPEP, 
C.F.R., or relevant case law to support the Examiner's position. 

However, the Examiner provided an Interview Summary that merely stated that 
the parties "had a lengthy discussion on the proper analysis of 'conditional language'" 
but "an agreement was not reached." Interview Summary mailed January 1 5, 2004. The 
Interview Summary mailed January 15, 2004, purported to explain the nature of the 
Examiner's position using "Appellant's representative's interpretation." Id. However, the 
"interpretation" set forth is not Applicant's. Applicant submitted a clarifying Interview 
Summary and again requested written explanation of, and support for, the Examiner's 
orally articulated new grounds of rejection. The Examiner asserted that rather than 
consider the affirmatively claimed "if-then" statement, the Examiner considered the "if- 
not" statement. Id. The Examiner stated that "Applicant's representative... desires the 
Examiner to ignore the 'if not' and limit the analysis to only the 'if then.'" Id. This is 
exactly what Appellant requests. An analysis of the claims as presented, not some 
fictitious claim that includes "if-not" elements. The only limitation that should be 
analyzed are those in the claims. The "if-not" is unclaimed and irrelevant. 
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9. CONCLUSION 

At least in view of the above remarks, Appellant respectfully submits that the 
Examiner has provided no supportable position or evidence that claims 1-26 are 
anticipated under § 102(e) or obvious under § 103(a). Accordingly, Appellant respectfully 
requests that the Board find claims 1-26 patentable over the prior art of record and 
withdraw all outstanding rejections. 

General Authorization for Extension of Time 

In accordance with 37 C.F.R. §1.136, Appellant hereby provides a general 
authorization to treat this and any future reply requiring an extension of time as 
incorporating a request therefore. Furthermore, Appellant authorizes the Commissioner 
to charge deposit account no. 50-2402 the appropriate fee for an extension of time or any 
other fee which may be currently due, including the $320.00 fee for filing this Appeal 
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10. APPENDIX OF CLAIMS ON APPEAL 

1. (Original) A method to remotely enable software-enabled options 
comprising the steps of: 

receiving a user LD. at a centralized facility from a user; 
receiving an option-enabling request from the user specifying an option 
requested to be enabled in equipment at a subscribing station; 

at the centralized facility, confirming that the option has not already been 

enabled; 

sending an enabling feature from the centralized facility to the equipment 
in the subscribing station; and 

activating the option in the equipment. 

2. (Original) The method of claim 1 wherein the enabling feature is a 
software key designed to enable software already installed in the equipment. 

3. (Original) The method of claim 1 where the enabling feature is software 
to run the feature in the equipment. 

4. (Original) The method of claim 1 wherein the equipment includes 
medical imaging scanners. 

5. (Original) The method of claim 1 further comprising the step of designing 
a software key to enable the option for a predetermined trial period. 

6. (Original) The method of claim 1 further comprising the step of 
authenticating the user LD. after receiving the user LD. at the centralized facility. 
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7. (Original) The method of claim 1 wherein the step of sending an enabling 
feature includes downloading the enabling feature to the equipment and remotely 
enabling the feature automatically and without further user input. 

8. (Original) The method of claim 1 wherein the step of sending an enabling 
feature to the equipment includes sending the enabling feature by one of FTP and email 
to a field engineer for manual installation and enablement of the feature. 

9. (Original) The method of claim 1 further comprising the step of: 
verifying the option activation; and 

sending a verification email to the user confirming option enablement. 

10. (Original) An option-enabling system comprising: 

a subscribing station having at least one in-field product and at least one 
computer programmed to control the in-field product; 

an on-line center capable of receiving and authenticating a user I.D., 
validating an option request, and creating an option key in response thereto; and 

a communications network to relay data from the on-line center to the 
subscribing station, the communications network including a communications portion in 
the on-line center and a communications portion in the subscribing station, and further 
includes an ability to connect the on-line center to the subscribing station through an 
external communications network and transmit the option key from the on-line center to 
the subscribing station in response to a user I.D. receipt and authorization, and a valid 
option request receipt. 

11. (Original) The system of claim 10 further comprising a computer within 
the on-line center programmed to: 

receive a user I.D. at the on-line center from a user and validate the user 

I.D.; 

receive an option request from the user; 
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if the user LD. is validated, receive a system LD. and validate the system 

I.D.; 

if the system LD. is validated, check whether the option requested was 
previously enabled; and 

if the option requested was not previously enabled, enable the option 

requested. 

12. (Original) The system of claim 11 wherein the computer is further 
programmed to generate an option key specific to the system LD. 

13. (Original) The system of claim 12 wherein the computer is further 
programmed to: 

download and install the option key in medical equipment at the 
subscribing station; and 

verify option enablement in the medical equipment. 

14. (Original) The system of claim 13 wherein the computer is further 
programmed to send an electronic verification of the option enablement. 

15. (Original) The system- of claim 10 wherein the subscribing station 
includes at least one medical imaging device. 

16. (Original) The system of claim 12 wherein the computer is further 
programmed to FTP or email the option key to a user identified by the user LD. to allow 
the user to manually enable the option. 

17. (Original) The system of claim 12 wherein the computer is further 
programmed to generate the option key with a disablement feature to disable the option 
after a predetermined time period. 
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18. (Original) A computer program which, when executed by a computer, 
causes the computer to: 

receive an option-enabling request from a user to request an option to be 
enabled in a medical device located remotely from an on-line center; 

receive a system I.D. and validate the system I.D. with data from a 
database at the on-line center; 

compare the option-enabling request with any other option requests for 
that system I.D. in the database at the on-line center and reject the option-enabling 
request if the comparison results in a predefined number of matches; 

otherwise, generate an option key and forward the option key to one of the 
user and the medical device to enable the option. 

19. (Original) The computer program of claim 18 wherein the generation of 
the option key includes creating a disabling feature to disable the option after a 
predetermined number of days. 

20. (Original) The computer program of claim 18 wherein the computer 
program further causes the computer to receive and authenticate a user I.D. before 
receiving an option-enabling request. 

21. (Original) The computer program of claim 18 wherein the predefined 
number of matches is one. 

22. (Original) The computer program of claim 18 stored in memory of and 
incorporated into an on-line center that is connected to a plurality of subscribing stations, 
each subscribing station having at least one medical imaging scanner that has operational 
software that comprises modules, where at least one of the modules is optional and not 
operational and the option key is generated to automatically enable the at least one 
optional module. 
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23. (Original) A computer data signal embodied in a carrier wave and 
representing a set of instructions which, when executed by at least one processor, causes 
the at least one processor to enable an option in a device by: 

receiving a user I.D. at a centralized facility; 

receiving an option-enabling request specifying an option requested to be 
enabled in the device at a subscribing station; 

confirming that the option has not already been enabled; and if not, 

sending an enabling feature from the centralized facility to the device in 
the subscribing station; and 

activating the option in the device. 

24. (Original) The computer data signal of claim 23 wherein the enabling 
feature is a software key designed to enable software already installed in the device. 

25. (Original) The computer data signal of claim 23 wherein the device 
includes medical imaging scanners and further includes designing a software key to 
enable the option in the medical image scanner for a predetermined trial period. 

26. (Original) The computer data signal of claim 23 further causing the acts 

of: 

authenticating the user I.D. after receiving the user I.D. at the centralized 

facility; and 

wherein the act of sending an enabling feature includes downloading the 
enabling feature to the equipment and remotely enabling the feature automatically and 
without further user input. 
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